As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information, and may include one or more computer systems, data storage systems, and networking systems.
Advances in server virtualization have placed increased demands on physical network infrastructures. For example, there can be a need for more Media Access Control (“MAC”) address table entries throughout a switched network due to the potential attachment of hundreds upon thousands of Virtual Machines (“VMs”), each having its own separate MAC address. Also, VMs may be grouped according to their Virtual Local Area Network (“VLAN”), where thousands of VLANs might be needed in a given data center in order to partition traffic properly. The current VLAN limit of 4094 can be inadequate in some situations. In response to these and other problems that arise through continuing server virtualization, protocols and framework for a virtual extensible local area network (“VXLAN”) have been proposed.
In general, a VXLAN is a protocol for running an overlay network on an existing infrastructure for Layer 3 (“L3”) (i.e., a network layer), such that a virtual network is built to support elastic compute architectures. In essence, a VXLAN can connect multiple L3 networks and make them appear to share the same Layer 2 (“L2”) domain. This allows VMs to reside in different networks and yet still operate as if they belong to the same L2. This is generally accomplished through the use of particular VXLAN-based network structuring, identifying, addressing and encapsulating, among other modifications to traditional VLAN systems. In effect, VXLAN can be considered a tunneling scheme with VM hosts (e.g., ESX hosts) or “hypervisors” that are VXLAN Tunnel End Points (“VTEPs”). Other details of VXLAN can be found at, for example, the Internet website http://datatracker.ietf.org/doc/draft-mahalingam-dutt-dcops-vxlan/, which is incorporated by reference herein for this purpose.
The introduction of such VXLAN solutions to the various foregoing problems, however, can result in further issues with respect to such new solutions and protocols. One problem can involve issues that arise when separate multicast trees are provided for one, more, or all tenants on a VXLAN. Another problem can involve issues that arise when separate multicast trees are provided for each multicast stream within a given tenant. In these and other instances, an excessive concentration of traffic on relatively few links across the VXLAN can present a real problem in operating the VXLAN effectively.
Although many systems and methods for providing server virtualization have generally worked well in the past, there is always a desire for improvement. In particular, what is desired are systems and methods that are able to take the tendency of network traffic to concentrate on only a few network links and distribute the overall load of traffic effectively across an entire VXLAN topology instead.